A Multicast Distribution Tree (MDT) or “tree” is used to connect a source or transmitter router to all destination or receiver routers. The source or transmitter router forms the root node of the MDT, while the destination or receiver routers form the leaf nodes of the MDT.
One way of creating an MDT is by using Protocol Independent Multicast (PIM). Nodes may join and leave a MDT at any time using PIM Join/Prune messages, as described in more detail in the various related Internet Engineering Task Force (IETF) protocols. A PIM Join message sent by a given node identifies one or more multicast distribution trees that that node wishes to join. Each tree is identified by the combination of a multicast group address and a source address (where the source address is possibly a “wild card”). Under certain conditions it can be useful, when joining a tree, to specify additional information or attributes related to the construction of a desired tree to be joined, such as a desired Reverse Path Forwarding (RPF) vector attribute as detailed in IETF Request for Comment (RFC) 5496. The RPF vector attribute specifies a proxy address or “proxy” to reach the source address.
IETF RFC 5384 of November 2008 entitled “The Protocol Independent Multicast (PIM) Join Attribute Format” describes a modification of the Join message that allows a node to associate attributes with a particular tree. The attributes are encoded in Type-Length-Value format.
Since it is possible for a router to receive conflicting attribute information from different downstream routers for the same type, RFC 5384 contemplates a “Conflicting Attribute” default procedure. Specifically, attribute information propagated upstream that results in conflicting attribute preferences is resolved via a tie-breaking mechanism to select the “better” attribute (e.g., selecting based upon the attribute from the PIM adjacency with the numerically smallest IP address). When a particular attribute type is specified, the specification may include a conflict resolution procedure specific to that type. If so, that conflict resolution procedure must be used instead of the RFC 5384 default procedure.
Thus, each time a “better” proxy is learned in the RPF vector attribute, that proxy is selected. In the case of selecting a “better” proxy, the process to switch to the better proxy will cause a prune to be sent to the original proxy and a join to be sent to the new ASBR. The pruning of the tree rooted at the original proxy will result in traffic loss, the duration of which will depend upon the time it takes to set up a tree with the new proxy. This Join/Prune process is repeated each time a “better” proxy is selected, resulting in network churned loss of state and other undesirable impact to the network.